Method and system for transferring content from a database to a file

ABSTRACT

The present invention provides a method of transferring content from a file and a database. In this case, the file includes content instances, each content instance being associated with a respective field, and each field having a respective type. The transfer is achieved by determining the type of each field, and then storing each content instance in a store in accordance with the determined field type of the associated field. Each content instance can then be transferred to the database in accordance with the determined field type. A similar procedure is provided for creating XML files based on content within the database.

BACKGROUND OF THE INVENTION

The present invention relates to a method and a processing system fortransferring content between a file and a database.

DESCRIPTION OF THE PRIOR ART

The reference to any prior art in this specification is not, and shouldnot be taken as, an acknowledgement or any form of suggestion that theprior art forms part of the common general knowledge in Australia.

The need for Enterprise Application Integration (EAI) that emerged inthe 1980s is likely to grow strongly as the Internet becomes trulypervasive and automated information flow between disparate applicationsbecomes an expectation. The EAI challenge is complex and two-fold.Firstly, a system is required to ensure that information available onone computer can automatically be made available on another computerwithout human intervention such as re-entering or e-mailing. Secondly,if the data formats are different, translation is necessary.

One common approach is Object Distribution where technologies such asCORBA or RMI are used to make a shared Business Object Model availableon separate application instances. The Object Distribution techniquetypically results in close coupling between the integrated applicationinstances. This implies low latency in information update, but anincreased dependence between the applications

Another approach is Message Passing where messages containingapplication data are sent between application instances. The MessagePassing technique results in loose coupling between the integratedinstances with an increased latency in information update but improvedapplication independence. The loose coupling places a burden on theMessage Passing infrastructure to ensure messages are delivered.

The task of business integration typically involves two applicationinstallations, each of which will generally have some form of datastore. The communication between them will use an application specificprogram at each end and Message Transport. These programs have twopurposes, to insert data from the source database into a message thatthe Message Transport can deliver; and to insert the data from areceived message into the target database.

Application integration using messaging requires a translation betweenthe application data format and the message format. The complexity ofthis translation depends on the similarity between the data format andthe message format.

Given a defined Message Format and a defined Target Structure, a customsolution can generally be developed to translate and map between theMessage Format and the Target Structure. However, this may only beuseable in a particular application. Its development requires the use ofskilled resources (in some cases highly skilled where the structures arecomplex). As a result the development cost is assigned to the singleinstallation, and ongoing software maintenance may be required to caterfor Message Format changes and Target Structure changes.

This form of architecture is useful in a number of scenarios.

A first scenario is Business to Business integration where independentbusinesses or sites require data integrity between logically orphysically different sites. For instance, a wholesaler may have need ofregular interchange of business information with a number of retailers.In this case the wholesaler will automatically distribute catalogue andpricing information from the wholesaler's financial system to theretailer's financial system. The retailer's financial system will sendorders for stock directly to the wholesaler's financial system. Thewholesaler's inventory management system will notify the retailer'sfinancial system of order dispatch. The retailer's inventory managementsystem will notify the wholesaler's financial system of receipt ofgoods, and the wholesaler's financial system will send an invoice to theretailer's financial system.

Another scenario is multi-tiered application integration with differentapplications fulfilling a variety of functions in an organisation. Forinstance, a business has a web-application capable of taking orders, awarehouse management system and a financial system. The web applicationwill send a request for stock availability to the warehouse managementsystem. The warehouse management system will report on stockavailability to the web application. The web application will sendconfirmation of payment details to the financial system. The webapplication will send order details to the warehouse management system.The financial system will send approval to ship to the warehousemanagement system.

SUMMARY OF THE PRESENT INVENTION

In a first broad form the present invention provides a method oftransferring content from a file to a database, the file includingcontent instances, each content instance being associated with arespective field, and each field having a respective type, the methodincluding:

-   -   a) Determining the type of each field;    -   b) Storing each content instance in a store in accordance with        the field type of the associated field; and,    -   c) Transferring each content instance to the database in        accordance with the determined field type.

Typically the file is an XML file, with each content instance being arespective node in the XML file. However, the techniques can also beapplied to other files, and in particular, files having a hierarchicalstructure.

Typically, when the file is an XML file, the method includes determiningthe field type from a document definition file. However, the field typemay be determined in other manners as appropriate to the type of file.

The database is typically a relational database having a number ofdatabase fields, each having a respective type. In this case, the methodusually includes transferring each content instance into a respectivedatabase field in accordance with the database field type.

Typically the method includes storing each content instance in databaseusing a respective query, the query being generated in accordance withthe field type and the database field type. In this case, the query istypically an SQL query.

The method of transferring each content instance to the database caninclude:

-   -   a) Creating one or more vacant locations in the query in        accordance with the field type;    -   b) Transferring each content instance into a respective vacant        location; and,    -   c) Applying the query to the database to thereby transfer the        content instance(s) to the database.

The method generally includes storing each content instance in a storeby:

-   -   a) Determining a mapping between each field type of the        associated field and each database field type;    -   b) Creating a store field corresponding to each content        instance, each store field being determined in accordance with        the field type of the associated field and the mapping; and,    -   c) Transferring the content instance to the respective store        field.

The method typically includes determining the mapping from apredetermined mapping stored in a store.

The method generally includes using a processing system, the processingsystem having a processor coupled to a store, the processor beingadapted to:

-   -   a) Receive the file;    -   b) Determine the field type of each field;    -   c) Store each content instance in the store; and,    -   d) Transfer each content instance from the store to the        database.

In a second broad form the present invention provides a processingsystem adapted to transfer content from a file to a database, the fileincluding content instances, each content instance being associated witha respective field, and each field having a respective type, theprocessing system including a processor adapted to:

-   -   a) Determine the type of each field;    -   b) Store each content instance in a store in accordance with the        field type of the associated field; and,    -   c) Transfer each content instance to the database in accordance        with the determined field type.

In this case, the processing system generally includes a memory, withthe processor being adapted to create the store in the memory.

The processing system is generally adapted to perform the method of thefirst broad form of the invention.

In a third broad form the present invention provides a computer programproduct for transferring content from a file to a database, the computerprogram product including computer executable code which when executedby a suitably programmed processing system causes the processing systemto perform the method of the first broad form of the invention.

In a fourth broad form the present invention provides a method oftransferring content from a database to a file, the database includingcontent instances, each content instance being associated with arespective database field, and each database field having a respectivetype, the method including:

-   -   a) Retrieving each content instance from the database;    -   b) Storing each content instance in a store in accordance with        the database field type of the associated database field;    -   c) Creating a file; and,    -   d) Transferring each content instance into the file, each field        having a respective type determined in accordance with the        associated database field type.

In this case, the file is typically an XML file, with the database beinga relational database as described above.

Accordingly, the method typically includes:

-   -   a) Creating the query including one or more vacant locations;    -   b) Applying the query to the database to thereby transfer each        content instance into a respective vacant location; and,    -   c) Transferring each content instance to the store.

The method generally includes:

-   -   a) Determining a mapping between each database field type of the        associated database field and each field type;    -   b) Transferring each content instance into a respective store        field, the type of the store field being determined in        accordance with the database field type; and,    -   c) Generating fields in the file in accordance with the database        field type of each associated database field and the mapping;        and,    -   d) Transferring each content instance from the store field to        the respective field.

The method generally includes determining the mapping from apredetermined mapping stored in a store.

The method generally includes using a processing system, the processingsystem having a processor coupled to a store, the processor beingadapted to:

-   -   a) Retrieve each content instance from the database:    -   b) Store each content instance in the store; and,    -   c) Generate the file.

In a fifth broad form the present invention provides a processing systemadapted to transfer content from a database to a file, the databaseincluding content instances, each content instance being associated witha respective database field, and each database field having a respectivetype, the processing system including a processor adapted to:

-   -   a) Retrieve each content instance from the database;    -   b) Store each content instance in a store in accordance with the        database field type of the associated database field; and,    -   c) Generate a file, the file including each content instance        associated with a respective field, and each field having a        respective type determined in accordance with the associated        database field type.

The processing system generally includes a memory, the processor beingadapted to create the store in the memory.

The processing system is preferably adapted to perform the method of thefourth broad form of the invention.

In a sixth broad form the present invention provides a computer programproduct for transferring content from a file to a database, the computerprogram product including computer executable code which when executedby a suitably programmed processing system causes the processing systemto perform the method of the fourth broad form of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

An example of the present invention will now be described with referenceto the accompanying drawings, in which:

FIG. 1 is a schematic diagram of an example of a system for implementingthe present invention;

FIG. 2 is a flow chart outlining the process of transferring contentfrom a file to the database;

FIG. 3 is a flow chart outlining the process of transferring contentfrom the database to a file;

FIG. 4 is a schematic diagram of an example of the functionality of theprocessing system of FIG. 1 when transferring content from a file to thedatabase;

FIGS. 5A and 5B are a flow chart detailing an example of the process oftransferring content from a file to a database;

FIG. 6 is a schematic diagram of an example of the functionality of theprocessing system of FIG. 1 when transferring content from the databaseto a file;

FIGS. 7A and 7B are a flow chart detailing an example of the process oftransferring content from the database to a file;

FIGS. 8A and 8B are a flow chart of the operation of the mapping whenstoring content from a file into the database;

FIGS. 9A and 9B are a flow chart of the operation of the mapping whenstoring content from the database into a file; and,

FIG. 10 is a schematic diagram of a second example of a system forimplementing the present invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

An example of apparatus suitable for implementing the present inventionis shown in FIG. 1.

As shown, the apparatus includes a processing system 1 coupled to adatabase 2. The processing system 1 is adapted to receive data fileshaving any one of a number of predetermined formats. The processingsystem 1 then operates to extract content from the data file, storingthe content in the database 2. Similarly, the processing system 1 isalso adapted to extract content from the database 2 and then output thecontent in the form of a data file having a selected format.

In order to achieve this, the processing system 1 typically is formedfrom a processor 10, a memory 11 and an interface 12, coupled togethervia a bus 13, as shown. The processing system may also optionallyinclude an I/O device 14, such as a keyboard and monitor, or the like,as well as a further external interface 15 for coupling the processingsystem 1 to external communication systems, as will be described in moredetail below.

It will therefore be appreciated that the processing system 1 may be anyform of processing system, such as a suitably programmed computer, suchas a lap-top, palm-top or desk-top computer, specialized hardwareprocessing systems, or the like. In any event, operation of theprocessing system 1 will be achieved by having the processor 10 executeappropriate application software as will be appreciated by those skilledin the art.

In use, the processing system 1 operates to extract content from thedatabase 2 and generate an appropriate output file, or alternativelyreceive a file and extract the content from the file, storing thecontent in the database 2.

Overview

The manner in which a file is received and the contents stored will nowbe described in outline with reference to FIG. 2.

As shown, a file including content stored in one or more respective filefields within the file is received at step 100 with the format of thereceived input file being determined at step 110.

Each content instance (each content instance being a respective piece ofdata or information within a respective file field) is then stored in arespective field within a data store at step 120.

At step 130 one or more queries are determined in accordance with thestored content instance(s) and the determined file format, before eachquery is used to extract a content instance from the data store andstore the content instance in the database as required.

Once this is completed, it will be appreciated that all of the contentinstances stored in the file are stored within respective fields in thedatabase 2.

An example of the way in which content may be output from the databasein the form of an output file will now be described with reference toFIG. 3.

As shown in FIG. 3, the process for retrieving content from the database2 is to firstly determine the content to be extracted from the databaseat step 200. This may be achieved for example by responding to a queryfor information received from an external source, or the like.

Once the content has been determined, the desired format of the outputfile is selected at step 210. One or more queries are then determined atstep 220, in accordance with the determined file format and the content.

Each query is then used to extract a respective content instance fromthe database 2, with each content instance being stored in a respectivefield within a data store.

Once all the required content instances have been stored in the datastore, an output file is generated including each content instancestored within a respective file field.

The manner in input of content into and the retrieval of content fromthe database will vary depending to a large extent on the types of filesinvolved and the nature of the database. Thus, whilst it will beappreciated that the techniques may apply to many different databasesand file formats, the remainder of the description will focus on anexample in which the files are XML files (eXtensible Mark-up Language),with the database 2 being a relational database.

However, these techniques may also apply to other forms of database suchas any scripted language database, and other marked-up file types, suchas HTML, SGML, or any hierarchical structure file format, or the like.

In any event, in the present example, as the database is a relationaldatabase, content is input into and extracted from the database usingqueries such as SQL (Structured Query Language) queries. However, otherquery forms may also be used as appropriate.

As will be appreciated by those skilled in the art, XML files by theirnature can vary in the elements and attributes used therein. In order toensure that the content of an XML file is correctly understood, allwell-defined XML files are associated with a respective Document TypeDefinition, which defines the elements and attributes used within thefile. Accordingly, the system uses a document definition or acombination of a document type definition and a mapping, to determinethe type of content contained in each of the fields within the XMLfiles. This allows the processing system to determine a mapping betweenfields in the XML file and the database, thereby allowing the content tobe extracted from the XML file and stored in the database, or viceversa.

Detailed Description

The manner in which this is achieved will now be described in moredetail.

In particular, an example of the functionality of the processing system1 when importing data into the database 2 will now be described withreference to FIG. 4. As shown, the processing system includes an XMLinterface 20 coupled to an XMLInserter 21. The XMLInserter 21 is in turncoupled to a NodeMapFactory 22, a NodeMap 23, the database 2, and a datastore 25, which is typically the memory 11. The NodeMap 23 is coupled toa NodeRules element 27, with each of the NodeMapFactory 22, the NodeMap23, and the NodeRules element 27 being coupled to an AdapterConfiguration 24 as shown.

It will be appreciated by those skilled in the art that thisfunctionality is achieved by having the processor 10 execute appropriateapplications software.

The operation of the system to import the content of an XML file willnow be described in more detail with respect to FIG. 5.

Firstly, at step 300 the XML file is received at the XML interface 20and transferred to the XMLInserter 21. It will be appreciated from thisthat the XML interface may therefore correspond to the interface 15 ifthe XML file is obtained from an external source or the like.Alternatively, the XML file may be received in other ways as will beappreciated by a person skilled in the art.

At step 310 the XMLInserter 21 determines the document type definitionassociated with the XML file. This may be achieved for example byexamining the elements and attributes contained in the XML file and thencomparing these to a list of elements and attributes contained withineach different document definition. However, typically each XML filewill include an indication of the document type definition associatedwith the respective file in the XML file itself.

Alternatively, the XMLInserter 21 may use other mechanisms fordetermining the XML structure such as an XML schema, or the like.

At step 320, an indication of the document type definition istransferred to the NodeMapFactory 22, which operates to determine amapping in the form of a node map, from the Adapter Configuration 24 atstep 330. Each node map indicates for a respective XML file type, thefields within the database 2 to which each node (element or attribute)type in the file should be mapped. Thus, this specifies the databasefields (or tables) where the content of each type of element andattribute within the XML file should be stored within the database.

In general, when the system is initially configured, it is necessary togenerate node maps for each type of XML file that is to be processed. Inorder to achieve this, the node maps may be either obtained from anexternal source, or generated manually if a required node map is notavailable. In order to generate a node map, an operative must examine anexample XML file of the desired type, and then consider where thecontent of the file should be stored within the database 2.

After this, the operative defines the node rules specifying how thecontent of each node (each type of the element or attribute) should bestored in the database. Once node rules are defined for each type ofnode within the document type definition of the respective XML type,then the node rules are stored in the form of a node map within theAdapter Configuration 24.

It will be appreciated from this that the Adapter Configuration 24typically includes a number of different node maps therein, with eachnode map corresponding to node rules for a different XML or other filetype.

Accordingly, the NodeMapFactory 22 uses the document type definition toselect the respective node map from the list of node maps stored in theAdapter Configuration. Once this has been completed, the NodeMapFactory22 transfers an indication of the node map to the XMLInserter 21 at step340. At step 350 the XMLInserter 21 transfers the determined node map tothe NodeMap element 23.

At step 360 the NodeMap element 23 uses the node map to determine noderules from the NodeRules element 27. The node rules specify for eachtype of node contained within the XML file, the destination to which thenode should be stored within the database. In any event, at step 370 theNodeMap element 23 transfers the node rules to the XMLInserter 21.

At step 380 the XMLInserter 21 creates the data store 25 within thememory 11. The data store 25 includes a respective field correspondingto each type of node within the XML file. Accordingly, this allows theXMLInserter 21 to use the node rules to map the content of each node(hereinafter referred to as a content instance) in the XML file into arespective field within the data store 25, at step 390. Thus, eachcontent instance within the XML file is placed within a respective fieldin the data store 25.

In general, whilst each content instance is stored in a respectivefield, there may be occasions when multiple content instances arecombined within a given field. This can occur for example when thedatabase 2 is only to include a single field covering multiple nodeswithin the XML file. Thus for example, the XML file may include threenodes for specifying a date, with one node referring to the year, one tothe month and one to the day. In this case, however, if the databaseincludes only a single field referring generally to dates, then thefield in the data store 25 may be formed by combining the contentinstances for each of the day, month and year nodes, thereby resultingin a single date content instance. It will be appreciated that contentinstances may also be split, say for example form a single date contentinstance into separate day, month and year content instances.

It will be realized that this technique may be applied to other forms ofnode, such as nodes containing name information or the like. Similarlythe situation can be reversed, such that a single node in the XML filecan be split into three content instances as the content is written intothe data store 25.

In any event, at step 400 the XMLInserter 21 generates SQL commands thatcause each content instance to be transferred from the respective fieldin the data store 25 into the database 12 as required.

An example of the functionality of the processing system 1 for exportingan XML file containing content from the database 2 will now be describedwith reference to FIG. 6.

As shown, the processing system 1 includes an XML interface 20 coupledto a XMLExtractor 30. The XMLExtractor 30 is in turn coupled to aXMLBuilderFactory 31 and an XMLBuilder 32. The XMLBuilder 32 is coupledto an XMLReportNode 36 which is in turn coupled to the database 2 and adata store 35. The XMLBuilderFactory 31, the XMLBuilder 32 and theXMLReportNode 36 are also coupled to an Adapter Configuration 34, asshown.

Again, it will be appreciated by those skilled in the art that thisfunctionality is achieved by having the processor 10 execute appropriateapplication software.

In any event, the manner in which the system operates to generate an XMLfile will now be described with more detail with reference to FIGS. 7A,7B.

Firstly, as shown at step 500, the XMLExtractor 30 receives instructionsto create an XML file. This may be achieved in a number of waysdepending on the circumstances. Thus, for example, a user of theprocessing system 1 may provide input commands via the I/O device 14,requesting that an XML file containing certain content is produced.

Alternatively however the processing system 1 may be adapted to generateXML files containing predetermined content on a predetermined basis.This may be required for example when generating reports, or to ensurecontent is correct within the database. In this case, the instructionsto proceed with the creation of an XML file may be stored in the memory11 before being implemented at a predetermined time. This may beachieved for example by storing a schedule in the memory 11 indicatingwhen predetermined XML files are to be created.

In any event, the XMLExtractor 30 transfers an indication of the XMLfile to be created to the XMLBuilderFactory 31 at step 510. At step 520the XMLBuilderFactory 31 obtains a report indication from the AdapterConfiguration 34. The report indication will typically be pre-specifiedto allow particular content to be extracted from the database 2, therebyallowing the specified XML file to be produced.

It will be appreciated by those skilled in the art, that the reportswill typically need to be pre-defined. In particular, the reports willneed to include SQL query templates including an indication of thecontent instances that are to be extracted from the database 2. Thiswill therefore need to include details of the relevant database fieldswithin which the respective content instances are stored.

Thus, the indication of the XML file to be created, which is received bythe XMLBuilderFactory 31 will include an indication of the content to beincluded in the file. This may be an indication of specific content, inwhich case, the XMLBuilderFactory 31 will select an appropriate report.Alternatively, the indication of the XML file to be created may includereference to a predetermined report stored in the Adapter Configuration.Thus, the indication may specify a predetermined report.

In any event, the XMLBuilderFactory 31 uses the indication of the XMLfile to be created to identify the desired report stored in the AdapterConfiguration 34. At step 530 the XMLBuilderFactory 31 transfers anindication of the identified report to the XMLExtractor 30, which thentransfers the report indication to the XMLBuilder 32 at step 540.

At step 550 the XMLBuilder 32 obtains the report, including the SQLtemplates, from the Adapter Configuration 34. The XMLBuilder 32transfers the report and the SQL templates to the XMLReportNode 36 atstep 560.

At step 570 the XMLReportNode 36 creates a data store 35 within thememory 11. Again, the data store 35 includes fields corresponding toeach of the fields in the database 2 from which content is to beextracted.

At step 580 the XMLReportNode 36 uses the SQL templates to generate SQLqueries. The SQL queries are used to query the database 2, causing therequired content instances to be transferred to the data store 35 atstep 590.

During this procedure, each content instance will be transferred into arespective field within the data store 35, with the data store fieldbeing selected in accordance with the database field from which thecontent instance has been extracted.

As in the case of storing content in the database 2, there may also besome combining or separation of the content instances from differentdatabase fields to form a single content instance for storage in asingle data store field, as will be appreciated by those skilled in theart.

At step 600 the XMLReportNode 36 transfers the content instances to theXMLBuilder 32, which then operates to transfer the content instances tothe XMLExtractor 30 at step 610. Finally, at step 620 the XMLExtractor30 constructs the XML file for output via the XML interface 20.

At this point each content instance will be used to form the content ofa respective node within the XML file, with the node type beingdetermined on the basis of the field within which the data is stored inthe database 2. Accordingly, it will be appreciated that in order toachieve this, it is necessary to use a mapping specifying to which nodetype the content of each database field should be mapped. The mappingwill again be determined in accordance with the respective document typedefinition, and stored in the Adapter Configuration 34.

In this case the XMLExtractor 30 will be provided with details of themapping to be used by the XMLBuilder 32, although any suitable method oftransferring the mapping to the XMLExtractor may be used.

Accordingly, the above described methodologies provide a simpletechnique for automatically storing the content of XML files in adatabase and/or retrieving content from the database to generate an XMLfile.

In particular, the use of the intermediate data store 25, 35 isparticularly beneficial as it ensures that the content is correctlyorganized within respective fields and nodes within the database 2 andthe created XML file.

The use of the data store also allows for manipulation of the contentduring the transfer between the database 2 and the XML file, for exampleby combining content instances as described above. This allowsvariations in the formatting of the database fields and the XML filenodes to be accounted for automatically as the data is transferred,simply by defining an appropriate mapping.

In addition to this, the use of the data store and appropriate mappingshelps ensure that the hierarchy of the data within the XML file isretained in the relational database 2. This is particularly beneficial,as it is normally complicated to attempt to re-create the XML filehierarchy within relational databases. In particular, it is oftennecessary to have an operative review the XML file in detail andconsider the hierarchy structure, then ensure that this hierarchystructure can be reflected in the relational database metadata. Incontrast to this, the hierarchy structure is automatically reflectedwithin the relational database by virtue of the methodology describedabove, and in particular by virtue of the use of the intermediate datastore and appropriate mapping.

In particular, content instances may be extracted from the XML file inaccordance with their hierarchy. Similarly, content instances may beextracted from the database 2 in such a manner that they logically formthe hierarchy when inserted into the XML file. This is possible becauseit is not typical for all the content instances to be transferred at anyone time.

Thus, in the case of extracting content instances from an XML file, thecontent instance of a given node in the hierarchy level, together withall the respective child node content instances, will typically betransferred to the data store 25 at step 390. The content instances arethen stored in the database 12 at step 400. Once this has beencompleted, the XMLInserter 21 then proceeds to handle the contentinstances of other nodes, and their associated child nodes.

Thus, the content may be processed hierarchically so that thehierarchical structure of the content may be reflected in the manner inwhich the data is transferred into the database.

This will now be described in more detail.

Thus, for example, as shown in FIGS. 8A, 8B, the processor 10 willinitially determine the required mapping (node map) in accordance withthe document type definition of the XML file at step 700. Once this hasbeen completed, the processor 10 will create the data store 25,including fields as specified in the mapping at step 710. In this case,the mapping will specify a respective field corresponding to each nodetype within the XML file, and accordingly, the processor can examine thenumber of each type of node in the XML file and create an appropriatenumber of fields in the data store.

Following this, the processor will examine the root node of the XML fileat step 720 and determine if the content contained therein is to betransferred to the database in accordance with instructions defined inthe mapping. If the content is to be transferred to the database at step730, then the processor copies the content to the respective field inthe data store at step 740.

If no content is to be copied, or once this has been completed, theprocessor 10 will move onto consider the next parent node at step 750.Again, if it determined that content is to be transferred at step 760,then the content is copied into the respective field within the datastore 25 at step 770.

Otherwise, the process moves on to consider the next child node for therespective parent node at step 780. Again, if it determined that contentis to be transferred at step 790, then the content is copied into therespective field within the data store 25 at step 800.

In any event, the processor then determines at step 810 if each childnode of the respective parent node has been processed. If not, theprocessor returns to step 780 to process the next child node. Otherwise,the processor proceeds to step 820 to determine if all the parent nodeshave been considered. In this case, if not all the parent nodes havebeen considered, the processor moves on to step 750 to repeat theprocess with the next parent node.

Accordingly, all the children nodes associated with a given parent nodeare processed before the next parent node is processed. Once all theparent nodes are processed, this procedure ends at step 830.

In any event, during this process the content may also be transferred tothe database 2. In general the transfer of data from the data store 25will be achieved by simply transferring the content of a specified fieldtype into a specific type of field within the database, as describedabove. This process is typically performed on a first-in-first-out(FIFO) basis, such that the content transferred to the data store first,is the first content to be transferred to the database. Furthermore, themapping may be arranged such that the content instances for each parent(and the associated children nodes) are transferred into the databasebefore the next parent node is processed. Alternatively, all the nodesmay be processed before the content instances are transferred to thedatabase.

The process is similar when data is extracted from the database 2, suchthat the content for a respective level in the XML file hierarchy may beextracted simultaneously, with the XMLReportNode 36 transferring thecontent instances to the data store 35 at step 590. Once completed for afirst set of nodes in the hierarchy, the XMLBuilder can move on toobtain content for insertion in the nodes of the next level, such as thechildren nodes.

As a result of this, the XMLExtractor 30 receives content correspondingto each level in the hierarchy separately, thereby allowing thehierarchical structure of the XML file to be constructed as required.

However, in this case, it will be appreciated that the processor willnot initially know how many fields will be required in the store untilreports have been executed to determine the number of content instancesto be transferred.

Accordingly, the process is as outlined in FIGS. 9A and 9B. In thiscase, once the processor 10 will initially determine the requiredmapping in accordance with the content to be extracted from thedatabase.

The mapping will include one or more SQL Queries, which when executedwill each extract respective content from the database. Each query willcause the generation of a number of reports, depending on the databasecontent. Furthermore, each generated report will correspond to arespective root node, and will therefore correspond to a respectivefinal XML file. Accordingly, any given mapping definition may result inthe generation of a number of output XML files.

In order to handle this, the processor can merely determine the fieldtypes that need to be included in the data store at step 910, but notthe number of fields. Accordingly, at step 920, the processor transfersthe next query to the database, to thereby cause a number of reports tobe generated. The reports are returned to the processor at step 930,allowing the processor to examine the number of content instancesreturned by the report. This allows the processor to determine anappropriate number of fields of each type to include in the data store,at steps 940, 950.

At step 960, the processor 10 then transfers the content instance thatwill correspond to the root node to the data store. This is performed inaccordance with instructions in the mapping, such that the mappingdefines the content instance that will form the root node.

At step 970, the processor 10 transfers the content instance that willcorrespond to the next parent node to the data store, beforetransferring the content instance of the next child node at step 980. Atstep 990, the processor determines if all the content instancecorresponding to the child nodes have been determined, and if notreturns to step 980 until every child node corresponding to the firstparent node have been completed. Steps 970 to 990 are then repeated forthe remaining parent nodes, until all content instances have beentransferred to the data store.

The process can then end at step 1010, when the XML file is created.

Again, the content instances are preferably transferred from the datastore to the file in a FIFO fashion. In this case, the XML hierarchywill therefore be constructed automatically by virtue of the pre-definedmapping rules.

Once the first report is completed, the processor can return to step 940to consider the next report.

In any event, it will be appreciated from this that the use of themappings allow the structure of the XML file to be created automaticallyas the content is extracted from the database.

Alternative Architectures

In the example described above, the system is implemented using a singleprocessing system 1 coupled to database 2, however, the system can beimplemented using a wide variety of architectures which provide a widerange of functionality's using the methodologies described above.

Examples of this will now be described with reference to FIG. 10, whichis an example of a system incorporating a number of processing systems 1and databases 2. In particular, the system includes two local areanetworks (LANs) 4A, 4B coupled together via a communications network 3,such as the Internet, or the like.

As shown in FIG. 10, a number of processing systems 1 are providedcoupled to respective ones of the local area networks 4A, 4B and theInternet 3. A number of databases 2 are also provided. Finally, aresource database shown generally at 5 is also provided coupled to theInternet as shown.

In a first example the processing system 1A is directly coupled to adatabase 2A, allowing content to be transferred between the database 2Aand an XML file in the manner described above. However, in addition tothis, the processing system 1A can also be adapted to store or retrievecontent from any one of the other databases 2 which are coupled to theLANs 4A, 4B, or the Internet 3.

In particular, when the processing system 1A receives an XML file, thecontent of the XML file is temporarily stored in the data store 25before being transferred on to a database 2. By suitable configuration,the processing system 1A can be adapted to transfer the content directlyfrom the data store 25 to either database 2A, and/or any one of thedatabases 2.

From this, it will be realized that the processing system 1A can beadapted to ensure that a number of databases are updated simultaneously,even if the databases are provided at separate geographical locations.This situation is particularly useful for example when a companymaintains a number of different databases at distributed locations. Inthis instance, identical databases may be provided at differentgeographical locations for redundancy purposes. However, it can beimportant to ensure that the contents of each database are updated whenany one of the other databases are updated. Accordingly, in thisinstance the processing system 1A can be adapted to update each databasesimultaneously. Furthermore, as this only requires that contentinstances are copied from the data store 25 to a number of databases 2,there is little additional processing required.

Similarly, when an XML file is being created, the processing system 1Acan be adapted to query any one or more of the databases 2 to obtain thecontent instances. Thus, this allows information to be collected from anumber of geographically separate locations and incorporated into asingle XML file centrally.

It will be appreciated that in order for this to be possible, theprocessing system 1A may require access permission to access contentcontained within any one of the databases 2.

A second example of the manner in which the methodology may be used isto allow content to be transferred between two databases 2A, 2B.

In this example, if it is desired to transfer information from thedatabase 2A to the database 2B, there can sometimes be problemsoccurring for example if the database 2A, 2B have different relationalstructures, or include information stored in different formats or thelike. In this instance, in order to overcome the problem the processingsystem 1A can be used to generate an XML file containing any informationto be transferred to the database 2B, in the manner described above.

When the XML file is created, this is achieved by extracting contentfrom the database 2A in the normal way to form an XML file having apredetermined standard. The XML file can then be transferred via the LAN4A, the Internet 3 and the LAN 4B to the processing system 1B. Theprocessing system 1B can then extract the content from the XML fileusing the received document type definition, and an appropriate mapping,thereby allowing the content to be transferred into the database 2B inaccordance with the manner described above.

By converting the content into an intermediate XML file, this allowsdate to be transferred between two databases, even if the databasesstore content in different fields and have a different overallstructure.

It will be appreciated that in order for this to be achievedsuccessfully it will be necessary for each processing system 1A, 1B tobe provided with respective mappings in each Adapter Configuration 24,34.

In order to aid this, the centralized database shown generally at 5, maybe provided to include details of document type definitions andassociated mappings. The centralized database 5 can then be used as areference resource by each of the processing systems 1, 1A, 1B, 1C asrequired.

Thus, for example, if the processing system 1A obtains an XML filehaving a previously document type definition previously unencountered bythe processing system 1A, then the processing system 1A can access thedatabase 5 to determine if the document type definition is containedtherein. Once the document type definition has been located, theprocessing system 1 can proceed to determine if an appropriate mappinghas already been determined to map the nodes of the document typedefinition into a respective fields within the database. This wouldoccur for example if standard database structures are used in more thenone location, such that a mapping is already defined for example for thedatabase 2B, which has an identical field structure to the database 2A.

FIRST SPECIFIC EXAMPLE Inserting Content

A specific example of the insertion of the content of an XML file intothe database will now be described with reference to FIG. 4.

In this example, each of the different functional elements in theprocessing system is capable of executing respective commands to achievethe desired operation. In particular, the functions used are as set outin table 1.

TABLE 1 Functional Element Command XmlInserter 21 InsertDoc(doc)NodeMapFactory 22 getNodeMap(docId) NodeMap element 23 getRules(nodeId)createDataStore( ) Data Store 25 getValue(valueId) setValue(valueId,value) populateStatement (stmt) NodeRules element 27 startInsertendInsert startClear endClear defaultValue valueId valueField

In this case, the Message Interface 20 operates to locate an XMLdocument from a set of known document types to be inserted. The MessageInterface 20 uses “insertDoc(doc)” on the XmlInserter 21 to insert theXML document. In order to achieve this the XmlInserter 21 uses“getNodeMap(docId)” on the NodeMapFactory 22 to look up the NodeMap 23for this document. The NodeMapFactory 22 uses the Adapter Configuration24 to determine each Document's NodeMap. The XmlInserter 21 uses“createDataStore( )” on the NodeMap 23 to prepare a new DataStore 25 forthis XML document. The XmlInserter 21 locates the XML document'sDocument Node and processes the Node, keeping a register of SQLstatements to be executed. The XmlInserter executes all registered SQLstatements on the Database 2.

For each Node the XmlInserter 21 uses “getRules(nodeId)” on the currentNodeMap 23 to look up this Node's NodeRules 27. This set of NodeRulesdefines default conditions, SQL templates for execution at the start andend of the Node, and a DataStore valueId for the storage of this Node'sdata. The XmlInserter 21 adds the “Start of Node” SQL statement (if any)to its register of SQL statements. The XmlInserter 21 stores this Node'sdata into the DataStore value specified by the valueId. The XmlInserterlooks up each child Node of this Node and recursively processes eachchild node. The XmlInserter 21 adds the “End of Node” SQL statement (ifany) to its register of SQL statements. The XmlInserter 21 uses“populateStatement(stmt)” on the DataStore 25 to populate the alreadyregistered “Start of Node” and “End of Node” statements.

An example of the XML document to be inserted is shown below:

Document Type Definition: <?xml encoding=“US-ASCII”?> <!ELEMENT Account(Update)> <!ELEMENT Update (Name, Total)> <!ATTLIST Update UserId CDATA#REQUIRED> <!ELEMENT Name (#PCDATA)> <!ELEMENT Total (#PCDATA)> ExampleXML document <?xml version=“1.0” encoding=“UTF-8”?> <!DOCTYPE AccountSYSTEM “http://ourserver/accountupdate.dtd”> <Account> <UpdateUserId=“5”> <Name>John Doe</Name> <Total>15.26</Total> </Update></Account>

The structure of the database 2, includes USER and ACCOUNT tables, asshown in tables 2 and 3 below.

Table 2 Table 3 Field Name Field Type Field Name Field Type USERIDInteger

USERID Integer NAME Varchar TOTAL Decimal

A simple Intermediate Data-Store that allows the update of the abovedatabase from the XML document might be as shown in table 4.

TABLE 4 Value Id Value Type UserId String Name String Total String

The following XML element contains sufficient information to configurean adaptor capable of performing the required mapping:

 1. <?xml version=“1.0”?>  2.  3. <NodeMapMapId=“http://ourserver/accountupdate.dtd”>  4. <NodeRulesNodeId=“Account.Update”>  5. <EndInsert>update accounts setname=‘_$Name$_’ where userid=_$UserId$_</EndInsert>  6. </NodeRules>  7. 8. <NodeRules NodeId=“Account.Update.UserId”>  9.<ValueId>UserId</ValueId> 10. </NodeRules> 11. 12. <NodeRulesNodeId=“Account.Update.Name”> 13. <ValueId>Name</ValueId> 14.</NodeRules> 15. 16. <NodeRules NodeId=“Account.Update.Total”> 17.<ValueId>Total</ValueId> 18. <EndInsert>update accounts settotal=_$Total$_ where userid=_$UserId$_</EndInsert> 19. </NodeRules> 20.21. <Value ValueId=“UserId” Type=“String”/> 22. <Value ValueId=“Name”Type=“String”/> 23. <Value ValueId=“Total” Type=“String”/> 24.</NodeMap>

The NodeMap element for MapId “http://ourserver/accountupdate.dtd” (line3) declares that this configuration is to used for XML documents of thedefined type.

The NodeRules Element with NodeId=”Account.Update” (lines 4 to 6)declares the following:

-   -   These rules apply to the XML Node “Update” which is a child node        of the XML Node “Account”;    -   At the end of this element the SQL Template “update accounts set        name=‘_$Name$_’ where userid=_$UserId$_” is to be used        -   The String _$Name$_ is replaced with the content of the            Data-Store value “Name”.        -   The String _$UserId$_ is replaced with the content of the            Data-Store value “UserId”.

The NodeRules Element with NodeId=”Account.Update.UserId” (lines 8 to10) declares the following:

-   -   These rules apply to the XML Node “UserId” which is a child node        of “Update” which is a child node of the XML Node “Account”;    -   The data content of this node is to be stored in the Data-Store        value “UserId”.

The NodeRules Element with NodeId=”Account.Update.Name” (lines 12 to 14)declares the following:

-   -   These rules apply to the XML Node “Name” which is a child node        of “Update” which is a child node of the XML Node “Account”;    -   The data content of this node is to be stored in the Data-Store        value “Name”.

The NodeRules Element with NodeId=”Account.Update.Total” (lines 12 to14) declares the following:

-   -   These rules apply to the XML Node “Total” which is a child node        of “Update” which is a child node of the XML Node “Account”;    -   The data content of this node is to be stored in the Data-Store        value “Total”;    -   At the end of this element the SQL Template “update accounts set        total=_$Total$_ where userid=_$UserId$_” is to be used.        -   The String _$Total$_ is replaced with the content of the            Data-Store value “Total”.        -   The String _$UserId$_ is replaced with the content of the            Data-Store value “UserId”.

The Value elements (lines 21 to 23) declare the appropriate values inthe Data-Store.

SECOND SPECIFIC EXAMPLE Extracting Content

A specific example of the creation of an XML file from database contentwill now be described with reference to FIG. 6.

In this example, each of the different functional elements in theprocessing system is capable of executing respective commands to achievethe desired operation. In particular, the functions used are as set outin table 5.

TABLE 5 Functional Element Command XmlBuilderFactory 31getReportBuilder(reportId) XMLBuilder 32 getReport( ) Data Store 35getValue(valueId) setValue(valueId, value) populateStatement (stmt)XMLReportNode 36 XMLName XMLType Statement Children appendNode(doc)appendNode(element)

In this case, the XmlExtracter 30 identifies that it needs to generatean XML document. It calls “getReportBuilder(reportId)” onXmlBuilderFactory 31 to create an XmlBuilder 32 configured to generatethe correct XmlDocument. The XmlBuilderFactory 31 determines theXmlBuilder configuration details from the Adapter Configuration 34. TheXmlExtracter 30 calls “getReport( )” on the XmlBuilder 32 to generatethe XML Document. The XmlBuilder 32 determines the Database 2, DataStore35 and XML Document details from the Adapter Configuration 34. TheXmlBuilder 32 determines the XML Document's XmlReportNode 36 from theAdapter Configuration. The XmlReportNode 36 contains links to childXmlReportNodes which represent XML structure. The XmlBuilder 32 createsthe XML Document, and uses appendNode(doc)” on the XML Document'sXmlReportNode 36 to append the XML Document's document Node.

Each XmlReportNode 36 contains:

-   -   The name of the Xml Node to be generated.    -   The type of Xml Node to be generated (Element or Attribute)    -   The SQL Template to be used for retrieving data.    -   The valueIds for storing retrieved data in the DataStore

And XmlReportNode 36 links to child XmlReportNode

In this example the same XML Structure and database structure shown intables 2 and 3 is used. In this case the XML document will be extractedfrom the database.

An Intermediate Data-Store that allows the extraction of the XMLdocument from the given database might have the values shown in table 6.

TABLE 6 Value Id Value Type UserId String Name String Total String

The following XML fragment contains sufficient information to configurean adaptor capable of performing the required mapping:

 1. <Report>  2. <DocumentNode Name=“Account”/>  3. <DocumentIdType=“http://ourserver/accountupdate.dtd”/>  4. <ReportNodeName=“Account”>  5. <Element Name=“Account” >  6. <Query>Select Namefrom user where userid=_$UserId$_</Query>  7. <Result ValueId=“Name”/> 8. <ChildNode Name=“Account.Update”/>  9. </Element> 10. </ReportNode>11. <ReportNode Name=“Account.Update”> 12. <Element Name=“Update” > 13.<Query>Select total from account where userid=_$UserId$_</Query> 14.<Result ValueId=“Total”/> 15. <ChildNode Name=“Account.Update.UserId”/>16. <ChildNode Name=“Account.Update.Name”/> 17. <ChildNodeName=“Account.Update.Total”/> 18. </Element> 19. </ReportNode> 20.<ReportNode Name=“Account.Update.UserId”> 21. <Attribute Name=“UserId”ValueId=“UserId”/> 22. </ReportNode> 23. <ReportNodeName=“Account.Update.Name”> 24. <Element Name=“Name” ValueId=“Name”/>25. </ReportNode> 26. <ReportNode Name=“Account.Update.Total”> 27.<Element Name=“Total” ValueId=“Total”/> 28. </ReportNode> 29. <ValueValueId=“UserId” Type=“String”/> 30. <Value ValueId=“Name”Type=“String”/> 31. <Value ValueId=“Total” Type=“String”/> 32. </Report>

The Report element (line 1) indicates that this configuration fragmentis to generate a Report.

The DocumentNode element (line 2) declares that the adaptor adds the XMLelement defined by the ReportNode with Name=”Account” to the XMLDocument.

The DocumentId element (line 3) declares that the Document TypeDefinition for this Document is “http://ourserver/accountupdate.dtd”

The ReportNode element with Name=”Account” (line 4-10) is referred to bythe DocumentNode element and declares the following:

-   -   This ReportNode represents an XML element with the name        “Account;    -   The element contains a Query element with the data        -   “Select Name from user where userid=_$UserId$_”            -   The String _$UserId$_ is replaced with the contents of                the Data-Store value UserId.        -   The pre-populated value UserId determines report content;    -   The first result column of the above query is placed in the        Data-Store value “Name”;    -   A Child node (either an element or an attribute) is defined in a        ReportNode with the Name Account.Update. The Child node is added        to this element.

The ReportNode element with Name=”Account.Update” (line 11-19) declaresthe following:

-   -   This ReportNode represents an XML element with the name        “Update”;    -   The element contains a Query element with the data        -   “Select total from account where userid=_$UserId$_”            -   The String _$UserId$_ is replaced with the contents of                the Data-Store value UserId.        -   The pre-populated value UserId determines the report            content;    -   The first result column of the above query is placed in the        Data-Store value “Total”;    -   A Child node (either an element or an attribute) is defined in a        ReportNode with the Name Account.Update.UserId The Child node is        added to this element;    -   A Child node (either an element or an attribute) is defined in a        ReportNode with the Name Account.Update.Name The Child node is        added to this element;    -   A Child node (either an element or an attribute) is defined in a        ReportNode with the Name Account.Update.Total The Child node is        added to this element.

The ReportNode element with Name=”Account.Update.UserId” (line 20-22)declares the following:

-   -   This ReportNode represents an XML attribute with the name        “UserId”. The Attribute Value is obtained from the Data-Store        value “UserId”.

The ReportNode element with Name=”Account.Update.Name” (line 23-25)declares the following:

-   -   This ReportNode represents an XML attribute with the name        “Name”. The Attribute Value is obtained from the Data-Store        value “Name”.

The ReportNode element with Name=”Account.Update.Total” (line 26-28)declares the following:

-   -   This ReportNode represents an XML element with the name “Name”.        The Attribute Value is obtained from the Data-Store value        “Name”.

The three Value elements (line 33 to 35) declare three Data-Store valueswith Ids UserId, Name and Total, all of type String.

Persons skilled in the art will appreciate that numerous variations andmodifications will become apparent. All such variations andmodifications which become apparent to persons skilled in the art,should be considered to fall within the spirit and scope that theinvention broadly appearing before described.

1. A method of transferring content from a database to a file, thedatabase including content instances, each content instance beingassociated with a respective database field, and each database fieldhaving a respective type, the method including: a) retrieving eachcontent instance from the database by performing at least one query, thequery being adapted to extract content instances from the database as anumber of reports, wherein for each respective report: i) determiningthe number of content instances in the report; ii) generating arespective store field for each content instance in the report, thestore field type being determined in accordance with the database fieldtype; and, iii) determining a parent content instance; iv) transferringthe parent content instance to a respective store field; v) determiningany child content instances; and, vi) transferring the child contentinstances to respective store fields; and, vii) repeating steps (i) to(vi) for each report; b) generating store fields in a data store whereineach store field has a respective store field type in accordance withthe respective report; c) storing in the data store each contentinstance from each respective report in a respective store field inaccordance with the database field type of the associated databasefield; d) creating a file including a number of fields, each fieldhaving a type in accordance with the respective report; and, e)transferring from the data store each content instance into a respectivefield within the file, in accordance with the store field type.
 2. Amethod according to claim 1, the file being an XML file, each contentinstance being a respective node in the XML file.
 3. A method accordingto claim 2, the method including generating the field type of each fieldusing a document definition file.
 4. A method according to claim 1, thedatabase being a relational database, the method including transferringeach content instance to the store using a respective query, the querydetermining the database field type.
 5. A method according to claim 4,the query being an SQL query.
 6. A method according to claim 4, themethod including: a) creating the query including one or more vacantlocations; b) applying the query to the database to thereby transfereach content instance into a respective vacant location; and, c)transferring the content instance to the store.
 7. A method according toclaim 6, the method including: a) determining a mapping between eachdatabase field type of the associated database field and each fieldtype; b) creating store fields corresponding to each content instance,each store field being determined in accordance with the field type ofthe associated database field and the mapping; and, c) transferring eachcontent instance into a respective store field.
 8. A method according toclaim 7, the method including: a) generating fields in the file inaccordance with the database field type of each associated databasefield and the mapping; and, b) transferring each content instance fromthe store field to the respective field.
 9. A method according to claim7, the method including determining the mapping from a predeterminedmapping stored in a store.
 10. A method according to claim 1, the methodincluding using a processing system, the processing system having aprocessor coupled to a store, the processor being adapted to: a)retrieve each content instance from the database: b) store each contentinstance in the store; and, c) generate the file.
 11. A processingsystem adapted to transfer content from a database to a file, thedatabase including content instances, each content instance beingassociated with a respective database field, and each database fieldhaving a respective type, the processing system including a processorfor: a) retrieve each content instance from the database by performingat least one query, the query being adapted to extract content instancesfrom the database as a number of reports; wherein for each respectivereport: i) determining the number of content instances in the report;ii) generating a respective store field for each content instance in thereport, the store field type being determined in accordance with thedatabase field type; and, iii) determining a parent content instance;iv) transferring the parent content instance to a respective storefield; v) determining any child content instances; and, vi) transferringthe child content instances to respective store fields; and, vii)repeating steps (i) to (vi) for each report; b) generating store fieldsin a data store wherein each store field has a respective store fieldtype in accordance with the respective report; c) storing in the datastore each content instance from each respective report in a respectivestore field in accordance with the database field type of the associateddatabase field; d) creating a file including a number of fields, eachfield having a type in accordance with the respective report; and, e)transferring from the data store each content instance into a respectivefield within the file, in accordance with the store field type.